An introspection tool, such as the SystemTap introspection tool for the Linux® operating system, allows users, such as system administrators and software developers, to examine the activities of software (e.g., operating system, applications, programs) while the software is executing to help diagnose a performance or functional problem. An introspection tool can include tracing and probing features, for example, to allow a user to examine variables in the software code, and to ‘hook’ into the software code to gather information about the software. A user can use an introspection tool to create a user introspection script containing functions to examine and monitor software. The introspection tool translates and compiles the user script to create binary code (kernel module) that runs within the kernel, and loads and runs the kernel module to examine the software.
Traditionally, user introspection scripts have provided full system-wide instrumentation to system administrators, including visibility and manipulation capabilities into a kernel or arbitrary user processes. Unlimited full system-wide instrumentation, however, may be unsuitable for ordinary unprivileged users, such as software developers and performance analysis staff. Currently, an unprivileged user may have access to probe processes of other users and access to probe the kernel itself. There is not a mechanism to limit an unprivileged user to a safe subset of introspection tool functionality.
Limiting user access to this safe subset of functionality can be challenging, since an introspection tool involves the creation, loading, and execution of kernel modules, with complete theoretical control over the hardware. There are at least two problems. First, when generating the kernel module, safety constraints must be enforced during the translation and compilation of the user script. One solution may be that during the translation and compilation processes an introspection tool can check for the presence of any probe types or function calls that are not known to be safe for unprivileged users, and can immediately reject scripts that attempt to use them. An unprivileged user, however, could easily interfere with the translation and compilation processes to weaken the checks which may cause the safety promises to not hold. For example, an unprivileged may change temporary files, modify the running translation and compilation processes, and disable the checks. The second problem is that the system which is supposed to load and run the kernel module must ascertain that the appropriate safety constraints were in fact included in the kernel module. Even if a kernel module was translated and compiled properly, the kernel module might have been corrupted by the time it is presented to the system that is supposed to load and run the kernel module.